The changes in init_repo_file_classes() make sense to me.

As for the rest of the changes: it looks to me that the issue that triggers the addition of the option in RepoFileBase is the fact that RepoActionInvoker unconditionally uses YumRepo. Would you please provided a trace of the call stack that leads to the usage of RepoActionInvoker on debian-based systems? I'd rather fix that, than keep using a repo type (YumRepo) that does not belong to the current system.

Sure. Thanks @pinotree for you answer.

If you run subscription-manager repos:

  File "/usr/sbin/subscription-manager", line 33, in <module>
    sys.exit(load_entry_point('subscription-manager==1.29.35', 'console_scripts', 'subscription-manager')())
  File "/usr/lib/python3/dist-packages/subscription_manager/scripts/subscription_manager.py", line 73, in main
    return managercli.ManagerCLI().main()
  File "/usr/lib/python3/dist-packages/subscription_manager/managercli.py", line 92, in main
    ret: Optional[int] = CLI.main(self)
  File "/usr/lib/python3/dist-packages/subscription_manager/cli.py", line 197, in main
    return cmd.main()
  File "/usr/lib/python3/dist-packages/subscription_manager/cli_command/cli.py", line 410, in main
    return_code = self._do_command()
  File "/usr/lib/python3/dist-packages/subscription_manager/cli_command/repos.py", line 141, in _do_command
    repos = rl.get_repos()
  File "/usr/lib/python3/dist-packages/subscription_manager/repolib.py", line 222, in get_repos
    yum_repo_file = YumRepoFile(options = ['skip_creating_repo'])
  File "/usr/lib/python3/dist-packages/rhsm/repofile.py", line 564, in __init__
    RepoFileBase.__init__(self, path, name, options)
  File "/usr/lib/python3/dist-packages/rhsm/repofile.py", line 371, in __init__
    self.create()
  File "/usr/lib/python3/dist-packages/rhsm/repofile.py", line 405, in create
    traceback.print_stack()

So what if you replace the usage of YumRepoFile with AptRepoFile in RepoActionInvoker if HAS_DEB822 is defined? In the end, I don't see how using YumRepoFile in a debian-based would be correct, TBH...

Any thoughts on this PR @ptoscano ?

One question I have is: on a Debian system without this patch, what do you get when running subscription-manager repos?

/etc/yum.repos.d and a file red hat.repo containing the header.

Just to add - if you have rpm-repos in your Content View and run "subscription-manager repos", you might end up with repositories in redhat.repo causing other issues like breaking the package-profile-upload to katello

Can you run the tests @ptoscano ?

@jirihnidek Can you maybe give some feedback / start the tests?

@sbernhard I'm just testing/reviewing this PR.

Thanks for the PR. The file /var/lib/rhsm/repo_server_val/redhat.repo is still created, which could be still confusing. I have two also other requests, because you use wrong names of Python modules.

Yes, thats true. I thought, this repo_server_val is a "internal storage" which is required for the sub-man and not something a user would ever see.

Thanks for the PR. The file /var/lib/rhsm/repo_server_val/redhat.repo is still created, which could be still confusing. I have two also other requests, because you use wrong names of Python modules.

Yes, thats true. I thought, this repo_server_val is a "internal storage" which is required for the sub-man and not something a user would ever see.

Hmm, the code is wild. The file /var/lib/rhsm/repo_server_val/redhat.repo is still needed as "internal storage", but I would try to rename it to something like /var/lib/rhsm/repo_server_val/rhsm.sources to not look like an alien from Red Hat world. Thoughts?

Thanks for the PR. The file /var/lib/rhsm/repo_server_val/redhat.repo is still created, which could be still confusing. I have two also other requests, because you use wrong names of Python modules.

Yes, thats true. I thought, this repo_server_val is a "internal storage" which is required for the sub-man and not something a user would ever see.

Hmm, the code is wild. The file /var/lib/rhsm/repo_server_val/redhat.repo is still needed as "internal storage", but I would try to rename it to something like /var/lib/rhsm/repo_server_val/rhsm.sources to not look like an alien from Red Hat world. Thoughts?

Make sense in general. Maybe "a lot of things" need to be adapted because of tests etc. Should we rename this in a separete PR?

Thanks for the PR. The file /var/lib/rhsm/repo_server_val/redhat.repo is still created, which could be still confusing. I have two also other requests, because you use wrong names of Python modules.

Yes, thats true. I thought, this repo_server_val is a "internal storage" which is required for the sub-man and not something a user would ever see.

Hmm, the code is wild. The file /var/lib/rhsm/repo_server_val/redhat.repo is still needed as "internal storage", but I would try to rename it to something like /var/lib/rhsm/repo_server_val/rhsm.sources to not look like an alien from Red Hat world. Thoughts?

Make sense in general. Maybe "a lot of things" need to be adapted because of tests etc. Should we rename this in a separete PR?

You are right. We can do that in another PR.

Thanks for the PR. The file /var/lib/rhsm/repo_server_val/redhat.repo is still created, which could be still confusing. I have two also other requests, because you use wrong names of Python modules.

Yes, thats true. I thought, this repo_server_val is a "internal storage" which is required for the sub-man and not something a user would ever see.

Hmm, the code is wild. The file /var/lib/rhsm/repo_server_val/redhat.repo is still needed as "internal storage", but I would try to rename it to something like /var/lib/rhsm/repo_server_val/rhsm.sources to not look like an alien from Red Hat world. Thoughts?

Make sense in general. Maybe "a lot of things" need to be adapted because of tests etc. Should we rename this in a separete PR?

You are right. We can do that in another PR.

Is there something missing for this PR?

@jirihnidek / @ptoscano Any update for this?